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Proc£d6 de paiement Oectronique permettant d'effectuer des transactions 1i6es 
a I’acbat de biens surun reseau informs tique 

La presenle invention oonceme un precede de paiement ciectronique 
5 permettant d'effectuer des transactions lides a J’achat de biens offeds par des 
marchands au raoyen de services tdlematiques via un reseau de tdiecoramunication 
informatique ouvert sur Jequel sont connectes des postes serveuis dc marchands et 
des posies clients. 

Par reseau infoimatique ouvert, on entend id un reseau sur lequel des 
10 paiticuliers ou des eotreprises peuvent Iibremcnt se connecter a la condition de 
disposer d’une adresse, par exemple le reseau "Internet". Les biens concern6s sont 
dcs produits ou des services, dont la foumiture est realisee hors du reseau apres !a 
conclusion de la transaction, ou des biens immateriels, tels que des informations, 
dont la foumiture peut etre realisee via )e reseau infoimatique. 

15 Divers precedes de paieinent ciectronique ont ete proposes, certains 

6tant deja op6ratiomjcls. 

Plusieurs precedes sont fondes sur une nouvelle representation de la 
monnaie. 11 s'agjt d'une representation ciectronique, quelquefois denommee "jeton” 
qui peut etre purement Jogicielle ou partjcllement materieiie, par exemple avee une 
20 carte a puce. Ces precedes impiiquent la circulation de monnaie sur lc reseau 
infoimatique, ce qui pose des probleroes difficiles de security vis-a-vis dc la 
creation dc fausse monnaie. 

D’autres precedes cornrus de paiement ciectronique impiiquent une 
relation directe avec une banque ou un reseau bancaire. Typiquement, de tefe 
25 precedes sont employes dans les rfseaux dc carte dc credit comme, par cxcmple, 
des precedes bien connus utilisant des terminaux points de ventc relies a un circuit 
carte bancaire ainsi que des precedes utilisant des cheques 6Iectroniques avec tine 
signature eiectronique pour l’authentiScation de 1’acbcteur. Cest une forme dc 
lettre d'engagement fmise par un acheteur, remise au veodeur et accept6e et 
30 reconuue par une banque. 

Les proeddds qui impiiquent a un moment ou un autre de la transaction 
une relation avec le systeme bancaire traditionnel et la mise en oeuvre d’une 
transaction dans ce systeme prdsentent des inconv6nient$. Ainsi, les transactions 
danslc systeme bancaire ont un cout r6el qui devient prohibit]f lorsque le montant 
35 dc 1’achat est tres faible, par exemple un montant associe a la consultation d'une 
base de donnees. Or, les rescaux informatiques sont bien adaptes a la vente de 
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biens de faible valeur. prinripafcment des bicas d'information, puisque la livraison 
du bien peut se faire par le rEseau lui-meme, En outre, i'acces a un rEscau bancairt 
ou on reseau de carte bancaiie doit tire bautcment protege, ce qui exclut 
pratiquement la possible d’un acces a travels un reseau informalique ouvert, tel 
5 que le rescan "Internet" sur lequel des acheteurs pOtentiels peuvent se connecter. 

L'invention a pour but de fournir un procEde perenettant d’Eviter les 
inconvEnients des precedes conn us, cn particulier un prt>cEdE peiracttant, sans 
circulation de monnaie Electronique, de rEaliscr de fa$on simple ct fiable des 
transactions liees a I’acbat de biens sur un reseau informatique, et ce aussi bien 
10 pour des biens de prix cleve necessitant une autorisation par le systeme bancane 
rraditionnel, que pour des biens de faible ou ties faible prix- 

Cc but est atteint grace a un procede du type defini en tete de la 
presente description et compoitant, conformement a I’inveDtion, les 6tapes de : 

- elaboration par un posit serveur de mareband conned6 au rEseau 
15 d'une demandc d’antorisation de transaction, ou "ticket de paiement”, concemant 

un achat envisage entre le mareband ct un client, el comport ant des inform at ions 
relatives au marchand, au clieDt, a I'objet de 1'acbat et a son prix, 

- transmission du ticket de paiement via le reseau informatique a un 
postc serveur dc paiement distinct des postes clients et serveuis de marebands, 

20 _ verification automatique par le serveur de paiement si le paiement du 

prix est autorise pour le client conceme, la verification ctant cffcctuec, selon le 
montant du prix a payer, soil par interrogation d’un compte propre au client, tenu 
par le serveur de paiement, ct destine au paiement des perils montants, sou par 
interrogation sur un rEscau bancaire independent du reseau informatique, pour les 

25 paiements dc montants plus ElevEs, 

- si ia verification est positive, Elaboration par 1c serveur dc paiement 
d’une autorisation dc transaction ou bon de caisse comport ant au moms unc partie 

des informations du ticket de paiement, et 

_ transmission du bon de caisse au serveur de marchand via le reseau 

30 informatique, afin d’autoriscr la realisation de I’acbat. 

Ainsi, Jc piocEde scion l’invention est remarquable cn ce qu’il 
n’implique ni la crEation de monnaie electronique, ni la cuculation dc monnaie 

Electronique sur le reseau informatique. 

La gestion des transactions est cffectuEe par un serveur de paiement 

35 qui seul peur accEder a un reseau bancaire ou un reseau de carte bancairt, ct qui 
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gerc dcs comptes diems non bancaires sur lesquels des transactions de faibles 
mordants pcuvcDt etre cffectu£cs. 

Lc serveur de paiement gere egalement des comptes mar chan ds non 
bancaiies utilises pour les transactions de faibJcs montants. Ainsi, lorequ’un bon dc 
5 catsse est transmis apres verification par inttirogation d'un compte client tenu par 
1c serveur de paicmcDt, le montant dc I'achat est dibits du compte client et cifdjtf 
sur un compte marchand propre au roarchand concerne et tenu par le serveur de 
paiement, ce qui n'entralne pas des couts de trajtement Aleves. 

Chaque client dispose d’une identite qui lui est propre pour pouvoir 
10 utiiiser le precede de paiement. II doit egalement disposer d’un compte bancaire 
reel, de preference un compte utilisable au moyen du systeme traditionncl des 
cartes bancaires. La verification par le serveur de paiement peut comprendre une 
phase prfalable de validation de Pidentite du client a partir du contcnu du ticket de 
paiement. La validation de Pidentite esi une operation ptealablc a 1'acces eventuel 
15 au compte du client, si le montant de 1'achat est faible, et/ou a i'acces au reseau 
bancaire si le montant est plus £iev£. Le serveur de paiement comporte de 
preference des moyens, par excmple une base dc donn 6es, pennertant dc 
meraoriser ies relations entre les identity des clients utilises pour les transactions 
sur le r€seau informatique et des identites bancaires (numeros de comptes 
20 bancaires ou numeros de cartes de credit) utilisies pour les transactions sur le 

rescan bancaire. On peut eviter de la sorte la circulation d’identites bancaiies sur le 
reseau informatique. 

Un mode dc realisation de Prevention sera maintenaot decrit a title 
indicatjf, mais non liroitatif, cn reference aux dessins annexes sur Itsquels : 

25 - la figure 1 est une vuc generalc tres schematiquc d’un systeme dc 

paiement eicctronique conforme a rinvention; 

Ja figure 2 est une representation sous forme d’un schema bloc d'un 
serveur dc paiement du systeme de la figure 1; 

— la figure 3 illustre le d6rouleroent des operations relatives a un achat 

30 au moyen du systeme dc la figure 1 ; ct 

- les figures 4A 5 4C sent des organigrammes room rant ttes 
schematiquement les operations effeefttees par !c serveur de paiement. 

Sur la figure 1 est represents de fa$on tres schematiquc un teseau de 
telecommunication informatique 10 sur tequel sont connect^ dcs postes serveuis 

35 de marchands 20, des postes clients 30 ct au moms un poste serveur dc paiement 
40. 
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Le reseau informatique 10 est un reseau ouveit ou public, par exemple 
]e reseau denomme "Internet". 

Les serveurs de raarchands 20 sod! des unit £s telies que celles 
couramment utilises pour des serveurs tcldmatiques connect sur -bitenjet”, par 
5 exemple des unites organisecs autour de machines "Unix” muhiprocesscurs. 

Les posies clients 30 sont essentiellement des micro-ordinateuis qui 
sent munis dc moyens de connexion au reseau "Internet" 10, par exemple sous 
forme d’interface "Web'. Les serveurs de marebands 20 et dc postes clients 30 
utilisent par exemple des logiciefs connus sous la denomination "World Wide 

10 Web" (WWW) utilisant le protocole HTTP. 

Le serveur de paiement 40, monlre avec plus de details sur !a figure 2, 

comprend des unites frontale et dorsale respectivement 41 et 42 conneclces toutes 
les deux au reseau "Internet" 10. Uunite frontale 41 a une architecture semblablc a 
celle d'un serveur dassique connect sur un reseau tel qu^Intemet"". L'umt6 
15 dorsale 42 coroporte une unite de traitement 43 a un ou plusieure processeras, une 
base de donnees 44 comport ant des informations relatives aux marchands et clients 
abonnes au systdme de paiement, un registre dc transactions 45, une unite 46 
d’interfacc avec un reseau bancaire ou un reseau de carte bancaire 50, et un bus de 
communication 47 ou autre liaison siroilaire pennertant de relier entre eux les 
20 differents constants de Puniie dorsale 42. Une liaison sccurisec 48 permet une 
communication bidirectionnelle entre Purntd frontale 41 et 1’unitd de traitement 43. 
La communication avec le reseau informatique 10 est controls par 1’unite frontale 
41 tandis que la gestion de la base dc donnees 44 ainsi que le controlc de la 
communication avec 1c reseau bancaire 50 sont assures par Tunit6 dorsale 42. 

25 La base de donnees 44 contient des informations relatives aux clients 

et aux marebands abonnes au systeme dc paiement. Pour chaque client, la base de 
donnees 44 contient 1’jdentitd systeme du client ("Cld"), identity re^ue lore dc 
l’abonnemcnt au systeme, un comptc de client ou porte monnaic dlectromque 
("PME") destine au paiement de faiblcs montants, une identitd bancaire telle que 
30 numero de compte bancaire reel ou numero de carte de credit amsi 
qu'eventuelleroent une clef d'acces ou mot de passe propre an client. Four chaque 
marchand, la base de donnees 44 contient 1'identite systdrae du roareband ("Mid"), 
identite regue lore de l’abonnement au systeme, un compte de marchand, ou tiroir- 
caisse electronique ("TCE”) dcstind a reccaissement des faibles montants et une 
35 identite bancaire telle que nurodro dc comptc bancaire rde!. 
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La figure 3 iliustre sebematiquement ies differentes etapes d'une 
transaction poitarrt sur un achat d'un bien par un client abonne a un maichand 
abonne. II peut s’agir d’un bien materiel dont la livraison au client sera effcctufe 
reellement apres conclusion de la transaction ou d'un bien immat^riel (tel que de 
5 I'information) qui peut etre foumie au client par 3e reseau informatique d£s le 
paiement 6lcctTOnique effectue. 

(1) Consultation pai le client 

Par connexion sur Ic rfseau "Internet" 10, un client peut consultcr cn 
ligne le catalogue ou la "vitrine" d’un rnarchand quelconque par acces au serveur 
10 20 du rnarchand et par visualisation sur 1'ecran du poste client 30 des biens ou 

services du rnarchand. Sur presentation dc I'identite Cld du client, le serveur du 
rnarchand peut presenter au client des conditions financieres particulieres (par 
exemple une remise) applicables a la transaction evenluelle. 

15 Le choix du client 6tant arrete sur un bien O, ii est transmis au serveur 

du rnarchand sous forme d'un message contenant udc identite Old du bien et 
I’identite Cld du client. Lorsque cela est necessaire, par exemple pour !a livraison 
ulterieurc du bien choisi, des informations coroplimenlaires (par exemple udc 
adresse et un bora ire dc livraison pr6fer£). Cela peut etre realise de fagon 
20 commode en utilisant un formulaire electronique envoye sur le reseau et destine a 
eric rempli par le client. 

Dans le cas ou I'achat envisage represente un montant clev6 ou est 
soumis a des conditions legales, une authentification prealablc du client peut etre 
souhait£e. Comme on le vena en detail plus loin I'autbeBtification d'un clicDt est 
25 effectuec par le serveur de paiement 40. Aussi, une demande d’autbenlifi cation 
provenant d’un maichand est £mise avantageuscroent sous la fonne d’un ticket de 
paiement dc valeur nulie qut est transmis au serveur de paiement par le reseau 
informatique via le poste client ct, en cas d'authentification positive, provoque le 
retour d’un bon de caissc du serveur de paiement au serveur maichand, toujours via 
H) le poste client. Les procedures d’6tablissement d’un ticket de paiement et de renvoi 
d’un bon de caisse sont ddcrites plus cn detail ci-apres. 

La demande d’acbat troisc par le client peut porter sur un seul bien ou 
sur plusicurs biens 3 foumir de fagon groupie : "achat panier". 


En reponsc a une demande d’achat, le serveur rnarchand tlabore une 
demande de paiement qui peut com prendre ies informations suivantes : 
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- Identite du marchand, ("Mid"); 

- Description du bien commando, ou de chacim des biens du pamer, en 

cas d’acbats groupes; 

- Type de transaction (simple ou panier); 

5 - Identite du client, (’ Cld”), 

- Identity du bien ou de Pensemble des biens du panrer, ( Old ), 

- Prix de Pobjet, ("Oid”); 

- TV A (si applicable); 

- Date et heme de remission du ticket de paiement (hoiodatage par le 

10 serveur marchand); 

— Durec de validite du ticket de paiement, 

- Nurocro de serie dans le registie des ventes du marchand (notamment 
dans le cas oii la transaction a comporte une etape prealable d’authentificabon). 

L’enserable des informations ci-dessus esl encodee dans une chaine 
15 d T octets qui conslitue la chame opaque d'un ticket de paiement (ou URL de 
commando de bien, URL £tant les initiates de "Uniform Resource locator” ou 
Localisateur dc Ressource Umforme utilise dans les logiciels WWW avec 

protocoic HTTP), comine suit: 

URL bttp : < SP> < descriptif de la commando , 

20 oi. SP est i’adiesse "Internet' du se.vcur de paicraenl- Le ticket de paiement est 
adresse au poste dienl. II est compile pat deux 'ancles" logiques qui petmetlent 
au client soit de l'annuler, soit de le confirmer. 

( 4 ) firm d<r de paiement 

L’ordre de paiement est transits au serveur de paiement simplcment 
25 par validation par le client de PURL de demande de paiement. On compendia 
bien que le ticket de paiement ne fait alors que transitcr par le postc client. 

(*) dn bon de caisse 

Sur r 6 ception d’un oidre dc paiement, le serveur de paiement 40 lc 
d£code et precede a Pauthentification du client et recherche si le paiement pent etTe 
30 autorise avant de rctoumer un bon de caisse ou un refus de paiement. 

Les operations d’autbentification de client et d’autorisation de paiement 

seront decrites plus loin en detail en reference a la figure 4. 

Lorsque les verifications effectuees dc permettent pas d’autonser le 
paiement, une notification de refus molivec est adrcssec au client par le serveur de 
35 paiement (indiquant, par cxcmplc, compte insuffisamment approv.sionne, 
depassement d’un seuil autorise pour le client,...) 
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Lorsque Ics verifications effecfuees permettenl d'autoriser le paiement, 
lcs informations contenues darts le ticket de paiement sont completees avec un 
numero dc serie dans le rcgistrc des transactions 45, une estampille horaire, uoe 
duree de validity (typiquemcnt quelques dizaincs de secondes) ct le sccau du 
5 serveur de paiement constituant une information de certification. L’ensemblc dc 
ccs informations, yventuellement aprfes signature num£rique par rutilisaiion dc la 
partie de clef privee d'un systeme de chiffiement a clef privee/def publique du 
serveur de paiement (ce quj gaiantit la validite et I'integrite de J’autorisation de 
paiement), cst encode dans une chaine d’oetets qui constitue la ebaine opaque d'un 
10 bon de caisse ou URL de tivraison : 

URL http : <M> <descriptif du bon de caisse>, 
oil <M> est Ladresse "Internet" du marchand. 

(6) Demand? dc livraison 

Le bon dc caissc est transmis au serveur du marchand via le poste 
15 client. Ccci peut etre cffcctue automatiquement par le logiciel implante au poste 
client en utilisant la possibility de ic-routage des URL bien connue de Tbomme du 
metier. Avan! d’auloriser la livraisoD du bien, le serveur du marcbaDd op£re un 
decodage et udc verification du bon de caissc re 9 U. Cette verification consistc a 
uliliser la clef privee eventuelle du serveur de paiement, a verifier que la duree dc 
20 validity riest pas ecoulee, et a rapprocher le contenu du bon de caisse avec celui de 
la demande de paiement. 

( 7 ) Livraison du bien 

Lorsque le bon de caisse est valide par le serveur du marchand, celuj- 
ci peut effectuer la livraison direetc sur le poste client, dans le cas de bien 
25 d'ipformation, ou adressc au poste client un document pennettant le rttrait du bien 
ct pr£cisant notammenl le lieu de livraison el le nom du recipiendaire. 

On notera que, dans le cas d’un achat groups (panier), il y a creation 
par le serveur du marchand d’un objet avec affectation d’une identity unique. Cet 
objet est la liste dcs URL de cbacun des biens du panier. Cest cet objet qui est 
30 indique dans 1TJRL de commande de bien et qui permeftra d’enregistjer le detail 
des biens achetys dans le registre de transaction du serveur dc paiement. 

Lcs figures 4A a 4C montrent les op6rations effectu6es par Ic serveur 
dc paiement 40 en reponse a la ryception d’un ordre de paiement. 

Dans l’unity frontale 4] (figure 4A), 1’ordre de paiement est d£cody 
35 (ctape 61) ct sa validite est examinee (test 62) notammenl du point de vue de la 
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durfc de valjdite. Si le r6sultat dc 1'examen est irfgatif, one notification de refus cst 
envoyee au postc client (£tape 63). 

Si le rfeultat dc I’examen cst positif, il cst precede cnsuite a unt 
au.hertifca.ico do dico. (tape 64), le detail de core opetatioo dart. d£cri. plus 
5 loin cn rfftonce a la figure 4C. Si rau.beulifica.iou at n£gat.»e (lest 65), une 
no.ifica.ion dc refus csl unvote au clien. (tape 63). Si elle es. posi.ive, I'orfre de 
paienrent (ivertuellcocn. Iin.i.6 i l'iden.i.t Cld du client, a l'iden...« Mid du 
roarchand, e. au prix) es. trensreis via la liaison 68 a I'uni.6 dorsale 42 du sexveur 
de paienten. reprtsen* sut la figure 2 (tape 66). U liaison 48 esi une liaison 
10 securisee irteidisan. I’acces i l'unil£ dorsale a loule personne se conneOanl sur Ie 

reseau 10. 

L’unite frontale 41 attend aims que i'unite dorsale decide d’autonser ou 
non le paiement (etape 67). Si Ie paiement n’est pas antorise, (test 68), unc 
notification de refus est envoyee au posle client (etape 63). Si le parement est 
15 autorise, un bon de caisse est eiabore (etape 69), utiiisant les infonuat.ons 
emegjstrees a retape 62. Le bon de caisse est enregistr* dans une m&mom de 
runit€ frontale 41 (6tape 70) et est adiesse au serveur du roarchand v,a le poste 

client (etape 71). , 

Au niveau de l’uni.6 .locale 42 (figure 4B) du serveur de patement, a la 

20 reception d'un otdre de paiement au.hen.ifi£, il es. examine si ce!ui-ci doit «re 
autorise a paitir du comple client PME via le reseau bancaire 50. A ce. efiet, le 
prist es. compart a un seuil minimum (test 72). Ce seuil es. par ercmple de 

quelques dizaines de francs. ^ 

Si lc seuil est depass6, une demande pour effectucr l’operation de 

25 paiemenl es. lanc£e sur le reseau bancaire (tape 73) en utilisan. ridentile bancaire 
correspondau. a l’ideu.i.6 Cld du diert, telle qu'ellc reason de la cousultarion de la 
base de donates 44. A la rtceptiou de la rfponse posilive on negative (tape 74), 

celle-ci est transmise a I’unitd frontale 41 (etape 75). ^ 

Si Ie seuil n’est pas d6passe, le paiement pent etre effectue a parttr u 

30 compte PME du client. 

A cet effet, il est examine si le compte est suffisamment approvisionnfe 
(tesi 76). Dans la negative, un refus d'autorisation de paiement, e’est-a-drre une 
r6ponse negative, est renvoyie 4 ftinil£ frontale (6tape 75). Dans l’affirmafrve, le 
compte PME du client est debitd du prix el le compte TCE de marchand 
35 corresponds a lidentitd Mid est erudite du meme montanl (6Upe 7*0, 

transaction est inscrite dans le registre des transactions 45 (etape 78) ct 
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l’3utorisation de paiement, c’est-a-dire une reponse positive est transmise a l'urtite 
frontale 41 avec i’iudication du numero de seric de Tinscription dans lc registre de 
transactions (etape 75). 

La procedure d’authentification dans le serveur de paiement (figure 
5 4C) t a l'etape 64 de ia figure 4A, comprend 1'envoi au poste client, de preference 
dans une forrne securisie (cbiffirce), d’une demande de cfe d’acces, ou mot de passe 
(etape 641). A la reception securisec dc la cfe d’acces (£tape 642), une comparaisoD 
est effectuee avec une information conespondantc contenue dans la base de 
donnees 44 (test 643). 

10 Si la comparaison est negative, et qu’un nombre maximum de 

tentatives infructueuses n’a pas ete atteint (lest 644), on retoume a Ifetape 641. Si ce 
nombre maximum est atteint, 1’absence d'authentjfication est constatee, une alerte 
est produite (etape 645) et une reponse negative est envoyee au poste client (£tape 
646). L'alerte peut consister cn une annulation du compte PME ou en une 
15 surveillance de celui-ci arm de delectcr dc nouvclles tentatives d’utilisation. Si le 
test a l’etape 643 est positif, raulhentification est enregistrte (£tape 647) et une 
reponse positive est elaboree (etape 648). 

Des techniques de chiffrement permettant la transmission s£curis£c 
d’inforraations numcriques sur reseau informatique, notamment pour la demande 
20 d’envoi de cle d’acces et l’cnvoi de celle-ci, sont bien connues. 

La procedure d’authentjfication decrit ici permet d’effectuer une 
autbentification preaiable d'un client dans le cas ou celle-ci est necessaire avaot 
lfetablissement d'une demande de paiement par le serveur du marchand. Pour cette 
authentification, it suffit alois en effet de creer un ticket de paiement dans lequel le 
25 prix indique est nul, comme Lndiqud plus haut. 

L'cnregistremcnt des bons de caissc dam I’unife frontale permet aux 
clients et aux marchaxrds de proc£dcr a dcs contrdles et d’en obtenir 6ventuellement 
des copies. L’enregistrement des transactions dans l’unite doisaJe permet d’en 
conserver une trace en cas, par exemple, de contestation entre un client et un 
30 marchand. 

Les comptes clients PME geres par le serveur de paiement ODt cn 
principe un montant de solde plafonod et, selon le mode de realisation pfefere de 
I’invention, ils ne sont pas remuneres (le syst&me de paiemeDt se trouvant en 
dehors du monde bancaire). Un reapprovisionnement de son compte PME par un 
35 client peut etre effectue a partir de son compte bancaire, par ordre donn£ a son 
elablisscment bancaire. 
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Les comptes marchands TCE g6€s par le seivcur de paiement sont 
assodes a des comptes bancaires reels des marchands dans lesquels ils sont vidcs 
par exemple quotidiennemcnt. 

Bitn que 1’on ait decrit ci-avant un mode de mise en oeuvre dun 
5 precede selon 1’invcDtion dans un environnement "Internet" et avec des logjciels 
WWW utilisant le protocole HTTP, 1'bom me de l’art coroprendra aisement que 1c 
precede peut ctrc mis en oeuvre avec un reseau infoimatique autre qu" 1 Internet ou 
encore avec des logiciels serveur marchand et client n'utjlisant pas le protocole 
HTTP de WWW. En outre des procedes d'authentification securisis mettant en jeu 
10 des dispositifs matericls tels que lecteur de carte a puce ou rnoyen 

reconnaissance d'empreinte vocale pourront etre prevus a la place de dels d’accbs. 
Ces demicres et d’autre modifications qui viendiont a I’esprit du Vbomme du metier 
sont comprises dans la philosopbie et la portee de la presente invention. 
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RE VENDICATI ON S 

1. ProcEdE de paiement electronique pour des transactions liccs a l'achat 
de biens offerts par des marchands a des clients via un reseau informatique ouvert 
sur Icquel sont concedes des posies serveurs de marchands et des postes clients, 

5 caracterise par les etapes de : 

- Elaboration par un poste serveui de marchand connects au reseau 
d'unc dcmande d’autorisation de transaction, ou ticket de paiement, concemanl un 
achat envisage entre le marchand et un client, et comportant des informations 
relatives au marchand, au client, a Pobjet de l'achat et a son prix, 

10 - transmission du ticket de paiement via le reseau infonnatiquc a un 

scrveur de paiement distinct des postes clients et serveurs de marchands, 

- verification automatique par 3e serveur de paiement si le paiement du 
prix est autorise pour Ic client concerne, la verification Etant effectuec, selon le 
montant du prix a payer, soil par interrogation d’un com pie client propre au client, 

15 tenu par le serveur de paiement, et destine au paiement des petits roontants, sort par 
interrogation sur un reseau bancaire independant du reseau infonnatiquc, pour les 
paiemenls de montants plus ElcvEs, 

- si la verification est positive, Elaboration par le serveur de paiement 
d'une autorisation dc transaction ou bon de caisse comportant au moms une parlie 

20 des informations du ticket de paiement, et 

- transmission du bon de caisse au serveur de marchand via le reseau 
informatique, afin d'autoriser la realisation de l'achat. 

2. ProcEdE selon la revendication 1, caracterise cn ce que lorsqu’un bon 
de caisse est transmis aprfes verification par interrogation d'un compte client tenu 

25 par le serveur de paiement, le montant de 1’achat est dEbitE du comptc client et 
ciEdite sur un compte roarebamd propre au marchand concemc et tenu par le 
serveur de paiement. 

3. ProcedE selon Pune quelconque des revendications 1 cl 2, caractErisf 
en ce que la vErification par ie serveur de paiement comprend une phase prEalablc 

30 d’autbentification du client. 

4. ProcEdE selon la revendication 3, caracterisE en ce que 
rauthentification est realisEc par reconnaissance d’une clef d'accEs transmise par le 
reseau informatique du poslc client au serveur de paiement. 

5. ProcEde scion Pune quelconque des revendications 1 a 4, caractErise en 
35 cc qu’il comprend PElaboration pax le serveur de paiement d’un bon de caisse 
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comport ant au moins une panic des informations du ticket de paiement ct une 
information dc certification. 

6. Precede scion I’unc quclconque des revendications 1 a 5, caractense en 

cc qu'il comprend la memorisation par le serveur de paiement des transactions 
5 autorisees, par stockage d’au moms une partie du contenu des bons de caisse. 

7 Precede selon Pune quelcoDque des revendications 1 a 6. caractense en 

ce que le ticket de paiement cst transmis du serveur du marchand au serveur de 
paiement par l’intenn6diaire du poste client. 

8. Precede selon Pune quelconque de$ revendications 1 a 7, caractense en 
10 ce que le bon de caisse est transmis du serveur de paiement au serveur du 

marchand par Pintermediaire du poste client. 

9, Systeme de paiement electronique pour effectucr des transactions liees 
a Pachat de biens offerts par des marchands a des clients via un reseau infonnatique 
ouvert, le systeme comport ant des posies clients ct dcs posies serveurs de 

15 marchands pouvant ctre connedes sur le reseau ouvert, 

systeme caracteris£ en ce qu’il comporte en outre au moins un poste seiveur de 
paiement distract des posies clients et sciveurs de marchands et comprenant: 

~ une unil£ frontale munie dc moyens de connexion au rfceau ouvert, 

- une unite dorsale munie de moyens de connexion a un reseau 

20 bancaire independant du reseau ouvert, 

- des moyens dc communication entre les unites frontale et dorsale, 

- des moyens de memorisation de comptes de clients, de comptes de 

foumisseurs, et 

- des moyens de traitement pour, en reponse a la reception par Punitf 
25 frontale d’une demande d'autoiisation de transaction ou ticket de paiement, 

concemant un achat envisage entre un marchand ct un client, verifier si le paiement 
du prix est autorise pour le client conceroe par interrogation du coropte du client 
ou du reseau bancaire ct, si la verification est positive, laborer une autorisation de 
transaction, ou bon de caisse afin dc la transmctlre sur te reseau ouvert via Punit6 

30 frontale. 

10. Systeme de paiement selon la revendication 9, caractense en ce que le 

serveur de paiement comprend des moyens de memorisation des transactions 
autorisees. 
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